Developing and maintaining computer software has long been recognized as a difficult and error prone technology. Developers of application software and software integrators have sought compiler technology tools which provide instrumentation capabilities to optimize their software. Problems such as determining when memory array boundary conditions have been exceeded or when memory is uninitialized in the C and C++ programming languages have continued to exist and the need for improvements in software program monitoring tools is prevalent.
One problem with prior art software development tools is that such tools use a static process for adding instrumentation and monitoring code instructions. The use of a static process changed the execution of the object module from the way the object module would have originally executed to a new execution flow. Other processes used by static instrumentation or monitoring tools have expanded the user's original object code by adding steps to the software loading process by methods such as the insertion of instrumentation by a debugger, or of software fixes by adding patched code. The additional instrumentation and monitoring code allows the program under execution to track things such as memory boundary conditions, cache simulation, and software program flow. Software analysis for purposes such as code profiling is sometimes called code debugging. The patched code is used for purposes such as inserting software maintenance changes into object code modules. Since the original loader process is augmented to include a debugger or a code patching feature the executable memory image may contain the instrumentation code that was added during the augmented loading process.
In the previous types of software development tools such as computer instrumentation and monitoring tools, the translation of the original code occurs either on the original media image or at the point that the loader is invoked. After computer instrumentation and monitoring there no longer exists an executable image of the user's original code. Therefore, prior art limited the way the software development tools were used by altering the user's executable image with inserted instrumentation or monitoring code and thereby required the program counter to traverse both the user's original code instructions and the inserted instrumentation or monitoring code instructions.
All of these techniques for the use of static software development tools, which have existed in the past, have problems that have limited their efficiency. For instance, static instrumentation or monitoring tools require special linking. Additionally, since the type and scope of instrumentation needs may vary depending on particular program behavior at execution, in order to use a static instrumentation or monitoring tool effectively the user would need to periodically stop and look at the state of the optimized code, building up a history by using a series of code snapshots. These are time consuming activities.
Also, the static instrumented object code module does not include run-time information and consequently instrumentation or monitoring code will insert instructions for all paths of the software code even though many paths will not become part of the actual execution process. The lack of knowledge of the actual execution path of the user's object code module additionally hampers the programmer's ability to use the software development tools of the past with dynamically loadable libraries, such as the C language d11 library. The user would have to speculate at compile-time as to which dynamically loadable libraries would be included during the execution of the user's code and this may result in unnecessary code generation.
From the foregoing it will be apparent that there is still a need to create software development tools that retain the original execution flow of the user's code. This need exists because existing software development tools do not include run-time information and therefore efficiencies related to inserting instrumentation which is focused on the actual user code execution path cannot be achieved. Also, the run-time options chosen by the user cannot be propagated to the instrumented code in past dynamic tools. This results in less efficient means of instrumenting code. More recently a few dynamic tools have been developed that alter the monitoring code but still do not solve these problems.
These and other problems with the past static and dynamic software development tools have resulted in limitations on the further development of software development techniques.